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Introduction 


Several  significant  exploratory  and  advanced  development  programs  at  NOSC  are 
investigating  the  use  of  distributed  processing  methods  to  improve  fleet  commmand, 
control  and  targeting  systems.  Tactical  anti-submarine  warfare  (ASW)  information 
processing  systems,  for  example,  will  require  significantly  increased  connectivity  with 
computer  systems  on  both  their  own  platform  as  well  as  other  platforms.  In  the 
upgraded  ASW  systems,  new  data  sources  will  be  provided  from  systems  such  as  ACS 
(Afloat  Correlation  System)  to  improve  the  surface  scene  description  and  to  allow  better 
coordination  of  the  various  platforms.  This  need  for  increased  connectivity  among 
various  systems  may  be  well  served  by  the  application  of  distributed  operating  system 
technology.  In  this  role,  distributed  operating  system  technology  can  provide  an 
efficient  and  effective  means  for  the  integration  of  various  and  diverse  command  and 
control  data  processing  tasks. 

3BN  has  developed  a  distributed  operating  system.  Cronus,  which  functions  in  the 
context  of  a  heterogeneous  internetwork  system  architecture.  Cronus  is  intended  to 
introduce  coherence  and  uniformity  to  a  set  of  otherwise  independent  and  disjoint 
computer  systems.  Cronus  also  provides  a  development  methodology,  tools  and 
mechanisms  to  support  distributed  application  development  and  support  for  functional 
properties  Such  as  scalability,  resource  management,  and  survivability. 

"^he  Cronus  architecture  provides  a  flexible  environment  for  interconnecting  hosts  so 
that  facilities  available  on  one  host  may  be  conveniently  used  from  other  hosts.  Varymc 
degrees  of  host  integration  are  supported.  A  complete  host  integration  supports  a  we 
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developed  interprocess  communication  mechanism.  This  interprocess  communication 
mechanism  provides  all  the  functions  and  services  needed  to  simulaneously  support  a 
variety  of  distributed  processing  tasks.  More  limited  host  integration  schemes  focus  on 
the  support  of  particular  distributed  processing  functions  such  as  remote  login. 

The  need  to  provide  greater  connectivity  among  various  Navy  command  and  control 
systems  can  be  served  by  the  development  of  specialized  Cronus  interfaces.  In  general, 
these  specialized  Cronus  interfaces,  referred  to  as  Access  Systems,  are  examples  of 
limited  host  integration  schemes  which  support  the  task  of  acquisition,  translation  and 
transferral  of  data  from  an  external.  non-Cronus  information  system  to  a  variety  of 
clients  operating  in  a  Cronus  cluster. 

A  Cronus  testbed  featuring  an  Access  System  to  an  external  information  processing 
system  can  provide  an  additional  integrating  factor  for  Navy  applications  and  data 
sources.  Such  a  testbed  will  allow  a  diverse  set  of  applications  operating  on  a 
heterogenous  set  of  hosts  to  process  external  data  in  a  variety  of  ways  not  otherwise 
possible.  Of  particular  interest  for  such  applications,  is  the  development  of  an  interface 
between  a  Cronus  system  and  the  Naval  Tactical  Data  System  (NTDS/Unk-ll  system). 

A  system  to  provide  access  to  Link- 11  tactical  data  via  Cronus  would  allow  development 
and  testing  of  Cronus  applications  in  the  field  of  command  and  control  and  the 
P'esentation  of  meaningful  demonstrations  with  these  applications  in  a  realistic 
environment. 

This  report  explores  issues  related  to  the  functional  design  of  a  Cronus'LmK-i  l  access 
system  and  the  selection  of  a  suitable  hardware  base  for  its  implementation.  This 
document  will  aiso  develop  a  framework  for  the  integration  of  an  access  system  into  a 
NCSC  Cronus  testbed  and  will  highlight  applications  which  are  made  possible  by  such  an 
access  system.  Two  alternative  architectures  for  such  a  Cronus/Link-i  l  Access  System 
will  be  presented.  These  architectures  have  been  selected  and  developed  on  the  basis  of 
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the  haroware  available  lo  implement  these  systems.  From  these  two  architectures,  three 
possible  implementation  schemes  are  presented.  The  three  implementation  schemes  are 
examined  and  evaluated  in  terms  of  their  cost,  functionality  and  performance.  This 
document  does  not  address  the  numerous  detailed  technical  issues  related  to  the  actual 
implementation  of  a  Cronus/Link-11  access  system.  Instead,  the  development  of  these 
technical  details  is  best  withheld  until  selection  is  made  regarding  possible  Access 
System  architectures  and  implementations. 

§1.0  NTDS  Interface  Availability 

Suitable  alternatives  for  the  implementation  of  a  Cronus/Link-11  Access  System  are 
ultimately  limited  by  the  availability  of  hardware  devices  which  can  form  electrical 
interfaces  between  the  NTDS/Link-ll  system  and  other  systems  which  are  able  to 
support  Cronus  functionality.  From  this  starting  point,  investigation  into  a 
Cronus/Link- 11  Access  System  must  begin  with  the  evaluation  of  the  hardware  and 
software  systems  which  can  provide  (his  basic  interface  function. 

Unfortunately,  there  are  only  two  interfaces  currently  available  which  can  support  the 
Cronus/Unk-1 1  Access  System.  The  first  is  an  interface  device  which  interconnects  the 
NTDS/Link-11  electrical  protocol  and  the  IBM  PC  I/O  bus.  The  other  device 
interconnects  the  NTDS/Unk-11  electrical  protocol  with  the  DEC  LSI-11/23  Q-bus. 
The  following  sections  highlight  relevant  features  of  these  devices  and  the  software  to 
support  them.  A  third  alternative,  that  of  a  custom  hardware  device,  will  also  be  briefly 
discussed. 

§1.1  PC  Hardware  Alternative 

There  are  at  least  three  interfaces  available  for  interconnecting  an  IBM  PC  and  the 
NTDS/Link-11  data  system.  These  devices  are  manufactured  by  Rockwell  International 
American  Systems  Corporation  and  Sabtech  Industries  The  Rockwell  unit  not  a 
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commercial  product  and  thus  information  about  the  device  is  not  available.  The  Sabtecn 
Industries  unit  is  in  use  at  NOSC  and  was  recommended  over  the  American  Systems  jn;: 
The  Sabtech  unit.  Model  NT1632FS,  completely  implements  NTDS  MIL  STD  1397A  and 
can  be  configured  to  run  in  either  NTDS  ‘slow'  mode  or  NTDS  'fast'  mode  (16  nr  32  Oit 
operation).  Two  software  integration  tools  are  also  available  for  this  device.  The  first 
IS  a  stand-alone  NTDS  message  generator  which  provides  capability  to  quickly  perform 
loopback  tests  and  perform  general  system  tests.  The  second  software  tool  is  a  set  of 
assembly  language  routines  which  provide  high  level  language  access  to  the  interface. 
The  existence  of  these  tools  allows  for  rapid  development  of  new  PC  system  software  to 
interface  to  NTDS/Link-1 1 . 

The  interface  is  moderately  priced:  total  cost  is  about  $3700,  which  consists  of  $2900 
for  the  board,  $600  for  the  software  and  an  additional  $200  for  cables,  manuals  and 
loopback  plugs. 

§1.2  Q-bus  Hardware  Alternative 

A  number  of  years  ago.  Advanced  Computer  Communications.  Inc  developed  an  LSI- 
1 1/NTDS  interface  (called  the  IF11Q/NTDS).  This  device  is  DEC  Q-bus  compatible  and 
has  been  used  m  a  number  of  Navy  applications.  In  the  interest  of  increasing  the 
applicabilty  of  this  device,  ACC  developed  hardware  and  software  modifications  for  the 
interface  to  allow  compatibility  between  the  jiVAX  Q-bus-ll  and  the  NTDS  interface. 

This  device  has  limited  availability  and  is  expensive:  approximately  $13000  for  the 
board  and  associated  cables  and  software.  An  accurate  breakdown  of  this  price  was  not 
available  since  the  IF11Q/NTDS  product  is  only  available  on  request  for  quotation  basis. 
Pricing  and  lead  times  will  be  determined  at  that  time  based  on  ACC  staffing 
requirements  and  engineering  priorities,  interface  integration  problems  are  likely  to 
occur  due  to  the  limited  application  of  this  interface  to  the  VAX  environment  and  the 
solution  of  these  problems  will  likely  increase  the  cost  of  this  interface 
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§1.3  Custom  Hardware  Alternative 

A  third  alternative  for  the  interfacing  to  Link- 11  is  the  development  of  new  hardware. 
Currently  there  is  no  device  available  to  interconnect  NTDS  and  other  common 
microcomputer  standards  such  as  the  Multibus  architecure  used  in  the  SUN  2 
workstation,  or  VME  bus  architecture  used  in  the  SUN  3  workstation.  Since  both  of  these 
machines  support  Cronus,  development  of  such  an  interface  may  prove  useful  for  future 
flexibility  and  expansion  of  a  NOSC  Cronus  testbed. 


§2  Access  System  Architecture 


Before  presenting  descriptions  of  the  Access  System  architectures  made  possible  by  the 
NTDS  interfaces  described  in  the  previous  section,  it  is  useful  to  examine  the  basic 
elements  of  a  generalized  Access  System.  A  Cronus  Access  System  consists  of  three 
principal  functional  elements: 

•  External  Information  System  Interface  and  Interface  Driver/Server: 

This  element  allovirs  hardware-level  access  between  the  external  system 
and  a  Cronus  host  and  provides  high-level  I/O  and  low-level  protocol 
services  necessary  to  support  this  access. 

•  Translation  Module:  This  element  performs  the  necessary  conversions 
between  external  message  formats  and  Cronus  message  formats  to  allow 
data  exchange  between  the  two  systems. 

•  Cronus  External  Data  Manager:  The  External  Data  Manager  is  a  Cronus 
process  or  set  of  processes  responsible  for  control  of  communications 
with  the  external  system  and  the  manipulation  of  external  data  within 
the  Cronus  environment.  The  External  Data  manager  provides  access  to 
this  external  data  for  other  Cronus  processes  and  applications.  The 
Manager  may  also  provide  and  manage  bulk  storage  of  data  to  be 
exchanged  between  other  Cronus  Mangers  and  applications  and  the 
External  system. 


In  general,  models  of  how  to  implement  a  Cronus  access  system  can  be  constructed  by 
mapping  the  above  functional  elements  onto  suitable  hardware  components.  The 
following  sections  describe  two  architectures  tor  the  implementation  of  a  NTDS/Lmk- 
1 1  to  Cronus  access  system  based  on  the -hardware  options  presented  m  §1  1  and  §i  2 


I 
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§2.1  Gateway  Model 

The  gateway  moc=i  of  a  Cronus  access  system  is  based  on  the  division  of  responsibility 
between  two  physical  systems:  a  gateway  to  perform  protocol  translation  and  a  Cronus 
L:nk-ll  Manager  to  provide  access  to  Unk-il  data  to  other  Cronus  processes  and 
applications  (see  Figure  1).  The  model  makes  use  of  the  following  hardware  components: 

•  An  IBM-PC-AT  or  equivalent 

•  An  IBM-PC/NTDS  interface 

•  An  IBM-PC/Ethernet  interface 

•  A  Cronus  host  with  an  Ethernet  connection  ^ 

In  this  model,  the  PC  implements  the  following  access  system  components: 

•  A  Link-11  Server  to  manage  the  Link-11  interface  and  support  the 
protocols  associated  with  the  Link-11  network  system. 

•  A  TCP/IP  Module  to  manage  the  Ethernet  interface  and  provide  standard 
DoD  protocol  support  for  communication  with  a  Unk-11  Manager. 

•  A  Translation  Module  to  provide  two-way  translation  of  Unk-il 
messages  and  TCP/IP  messages. 

•  A  Connection  Server  to  manage  TCP/IP  connections  with  other  Cronus 
hosts  and  provide  access  to  control  facilites  for  the  PC. 

The  Cronus  host  in  this  model,  referred  to  as  the  Access  Machine,  in  addition  to  running 
the  standard  Cronus  kernel,  runs  a  Cronus  Unk-1 1  Manager  which  acts  as  the  External 
Data  Manager.  This  manager  is  responsible  for  the  establishment  and  control  of  TCP  IP 
links  to  the  PC,  for  the  transfer  of  data  to  and  from  the  PC  and  for  the  provision  of  data 
manipulation  mechanisms  to  allow  convenient  access  to  Link-ll  data  by  other  Cronus 
managers  and  applications.  The  Unk-11  Manager  may  also  be  responsible  for  the 
management  and  storage  of  large  sets  of  data  to  be  exchanged  between  the  two  systems 
The  degree  of  functionality  associated  with  this  data  storage  capacity  will  be  determines 
by  the  needs  of  applications  which  must  access  and  process  this  stored  data 


I,  lelefred  to  as  an  Access  Machine. 
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If  is  important  to  note  that  the  PC  in  this  model  implements  no  Cronus  functionality  in 
this  respect,  the  PC  functions  strictly  as  a  specialized  internetwork  gateway  which 
performs  message  format  translations  and  protocol  translations  beween  the  Link-ii 
system  and  a  generic  TCP/IP  environment.  It  is  for  this  reason  that  is  model  is  referrec 
to  as  the  'Gateway  Model*. 

The  Gateway  Model  presents  numerous  advantages  for  development.  At  a  fundamental 
level,  both  the  PC  and  the  PC/Link-i  1  interface  are  inexpensive  and  readily  available. 
Significant  portions  of  the  software  to  implement  the  PC  segment  of  the  access  system 
are  commercially  available  as  development  tools.  New  software  for  the  PC  would  be 
limited  to  the  control  and  translation  functions  and  to  code  to  integrate  commercially 
available  packages.  Also,  since  the  Gateway  Model  does  not  require  that  any  Cronus 
functionality  be  implemented  on  the  PC,  all  new  Cronus  code  (the  Unk-11  Manager, 
etc.!  would  be  implemented  on  ‘familiar'  systems,  eg,  ^.VAX  or  SUN. 

Following  is  a  summary  of  costs  and  issues  associated  with  the  development  of  a  PC- 
based  Gateway  Model  access  system; 

•  Machine  costs  are  low,  approximately  $9700 

•  Good  option  for  short  term  implementation,  ie,  there  is  only  a  moderate 
amount  of  software  of  known  complexity  that  need  be  developed 

•  Inexpensive  approach  for  both  prototype  stages  involving  few  units  and 
later  deployment  stages  involving  greater  number  of  units 

•  Exhibits  highly  specialized  functionality,  ie,  there  is  no  actual  Cronus 
features  are  supported 

•  Due  to  split  of  functionality  across  two  separate  machines,  there  may  be 
limitations  in  performance,  sercurity  and  reliability. 

§2.2  Access  Machine  Model 


The  hardware  required  to  implement  the  Access  Machine  Model  of  a  Cronus-  Unk-l  i 
access  system  is  variable.  Both  the  IBM-?C-AT  with  an  NTDS.'Link- 1 1  interface  and  the 
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)j.VAX  with  an  NTDS/Link-11  interface  could  fulfill  the  basic  requirements  for 
implementation  of  this  model.  Selection  between  these  alternative  configurations  is 
dependent  upon  actual  and  well  defined  needs  for  functionality  and  performance. 

In  the  Access  Machine  model,  the  Access  Machine  implements  the  following  access  system 
components  (see  Figure  2); 

•  A  Link-11  Server  to  manage  the  Link-11  interface  and  support  the 
protocols  associated  with  the  Link-ll  network  system. 

•  A  Translation  Module  to  provide  two-way  translation  of  Link-11 
messages  and  Cronus  Link-1 1  Manager  messages. 

•  A  Cronus  Link-11  Manager  to  provide  Link-11  data  manipulation 
mechanisms  for  other  Cronus  processes  and  applications  and  provide 
access  to  the  Link-1 1  Server. 

•  An  Cronus  Interprocess  Communications  Module  to  support 
communications  with  other  Cronus  processes  and  applications. 

•  A  TCP/IP  Server  to  manage  the  Ethernet  interface  and  provide  standard 
protocol  support  for  the  Cronus  Interprocess  Communications  module. 

The  Access  Machine  mode)  differs  in  architecture  from  the  Gateway  Model  in  that  the 
Cronus  Link- 11  Manager  is  resident  on  the  same  machine  that  directly  supports  the 
Unk-11  interface  and  Link-11  server.  In  the  Gateway  Model,  the  Link-11  Manager  is 
not  present  on  the  Link-11  interface  machine,  but  resides  on  some  other  Cronus  host. 

As  mentioned  at  the  beginning  of  this  section,  the  Access  Machine  Model  may  be 
implemented  using  either  a  uVAX  or  a  PC.  The  uVAX  and  the  PC  present  significantly 
different  architectures  and  performance  characteristics.  Although  the  PC  may  be  capable 
of  supporting  various  segments  of  Cronus  functionality,  its  lesser  processing  capacity 
may  not  leave  sufficient  reserve  to  provide  an  adequate  degree  of  flexibility  and 
extensibility  for  future  applications.  Conversly,  the  additional  processing  power 
provided  by  a  ij.VAX  will  make  possible  a  significantly  more  versatile  foundation  for 
implementation  of  an  access  system  at  additional  cost. 


Machine 
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There  are  two  approaches  to  use  of  a  PC  for  an  access  machine.  The  first  involves 
porting  a  Cronus  kernel  and  other  software  components  to  the  PC  through  the  use  of 
commercially  available  PC  UNIX  operating  system.  The  second  approach  involves 
development  of  a  new  multitasking  system  for  the  PC  which  is  specially  tailored  to  the 
needs  of  Cronus.  Both  approaches  have  their  merits  and  costs. 

Using  a  commercial  version  of  PC  UNIX  will  allow  for  a  relatively  rapid  and  easy 
implementation  of  Cronus  functionality  on  the  PC.  There  will  likely  have  to  be 
modifications  to  many  aspects  of  the  Cronus  kernel  and  associated  software,  but  the 
amount  of  effort  to  accomplish  this  will  be  relatively  small.  A  certain  amount  of  effort 
will  also  have  to  expended  initially  to  analyze  carefully  various  UNIX  systems  available 
for  the  PC  and  their  impact  on  a  port  of  Cronus.  A  limitation  that  use  of  PC  UNIX  may 
present  will  be  with  respect  to  performance,  it  is  possible  that  Cronus  is  too  large  an 
application  to  run  efficiently  on  a  machine  such  as  the  PC  supporting  UNIX.  Quantitative 
estimates  of  this  limitation  are  difficult  at  this  stage  of  investigation. 

The  second  approach  to  a  PC-based  access  machine  is  via  development  of  a  custom 
multitasking  system  for  the  PC  to  support  Cronus  directly.  The  principle  advantage  to 
this  approach  is  in  performance.  A  custom  multitasking  system  tailored  to  the  needs  of 
Cronus  can  be  optimized  to  provide  high  performance.  This  may  be  a  significant  issue 
for  a  relatively  small  machine  such  as  the  PC.  but  will  ultimately  depend  on 
performance  needs  of  Cronus  applications  using  the  access  system.  Support  for 
multitasking  has  been  previously  implemented  on  other  machines  for  Cronus,  but  the 
amount  of  effort  to  achieve  this  for  the  PC  is  still  undetermined  due  to  implementation 
complexities  caused  by  the  PC's  segmented  memory  architecture.  In  addition  to  the 
development  needed  to  support  multitasking,  new  device  drivers  for  the  multitasking 
environment  must  be  written  and  tested.  Once  a  complete  multitasking  environment  has 
been  established,  a  port  of  the  Cronus  kernel  and  other  system  software  must  be 
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performed.  Following  this,  other  software  to  support  access  machine  functionality  must 
be  developed.  The  principal  software  component  to  be  developed  is  a  Lmk-i  i  manager 
This  manager  will  support  NTDS/Link-11  protocol  service,  Cronus/Lmk- 1 1  format 
translations,  Link-11  data  storage,  and  access  mechanisms  for  other  Cronus  managers 
and  applications. 

Another  factor  which  will  affect  the  applicability  of  the  PC  to  the  Access  Machine  Model 
IS  the  need  for  bulk  storage  of  data  between  Cronus  and  the  Unk-l  l  system.  The  PC 
may  present  limitations  in  the  quantity  of  bulk  storage  and  the  rate  of  access  provided 
for  applications  which  require  such  functionality  regardless  of  what  approach  to  PC 
implementation  is  used.  Quantitative  analyses  of  such  limitations  are  difficult  without 
detailed  characteristics  of  the  bulk  data  access  needs  for  typical  Navy  tactical 
applications. 

''here  are  several  significant  advantages  to  an  Access  Machine  model  implemented  on  a 
a, VAX.  The  first  is  that  the  m-VAX  makes  available  significantly  increased  processing 
power.  This  extra  processing  capacity  will  allow  for  a  more  sophisticated  Lmk-li 
Manager  which  will  be  capable  of  supporting  complex  access  schemes  for  other  managers 
and  applications.  A  second  advantage  of  use  of  a  iiVAX  to  support  Lmk-l  i ,  is  that  efforts 
'0  implement  this  system  would  largely  involve  the  development  of  new  features  for  a 
‘amiliar'  system  which  already  supports  Cronus,  and  m  this  sense  provide  additional 
■average  from  previous  development  efforts.  New  code  for  a  u-VAX  access  machine  would 
nvolve  the  development  of  system  level  code  to  support  the  NTDS/Link-11  interface 
itself,  and  the  development  of  a  Link-11  manager  to  support  access  to  the  Lmk-il  cata 
for  other  Cronus  managers  and  applications. 

An  additional  advantage  of  a  uVAX  implementation  is  that  capacities  for  bulk  storage  of 
Link  1 1  data  are  significantly  greater  that  those  for  the  PC  The  tiVAX  provides 
capability  for  very  large  amounts  of  bulk  storage  and  has  the  processing  sceed  to  allow 
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rapid  and  flexible  access  to  such  storage.  Because  of  this,  the  )iVAX  will  allow  mucn 
greater  flexibility  in  providing  bulk  storage  facilities  for  tactical  applications  than  wi; 
a  PC-based  access  machine. 


A  summary  of  the  costs  and  issues  related  to  a  PC  implementation  of  an  Access  Machine  is 
as  follows; 

•  PC  and  Link-11  interface  are  relatively  inexpensive. 

•  Task  can  involve  either  short  term  development  or  longer  term 
development  depending  on  needs  for  performance.  PC-UNIX  version  is 
relatively  easy  to  implement,  but  may  offer  limited  performance;  a 
custom  multitasking  system  will  be  a  significant  effort,  but  will 
provide  a  high-performance,  optimized  system. 

•  All  development  and  operation  occurs  on  a  single  type  of  machine;  this 
may  be  an  advantage  m  terms  of  reliability  and  ease  of  development. 

•  May  be  expensive  alternative  if  only  a  few  access  systems  are  to  be 
procured:  cost  effectiveness  of  approach  will  appear  with  larger 
systems. 

•  May  provide  limited  bulk  storage  facilities. 


A  summary  of  the  issues  and  costs  related  to  a  implementation  of  an  Access  Machine 
IS  as  follows: 

•  Task  consists  of  relatively  short  term  development.  Cronus  kernel  and 
other  software  already  exists:  new  code  limited  to  Lmk-ll  server  and 
driver  and  Link- 11  Manager. 

•  p,VAX  and  Link-1 1  interface  expensive,  but  a  single  system  may  be  cost 
competitive  with  PC-based  system  if  uVAX  is  already  available  for  use. 
system  very  expensive  for  deployment  applications  involving  many 
units. 

•  Development  occurs  on  a  single  machine  with  an  existing  well- 
developed  and  tested  Cronus  envronment;  this  will  lead  to  a  shorter 
development  term. 

•  Can  provide  significant  facilities  for  bulk  storage. 


§3  Applications  for  a  Cronu&'Lmk-i  l  Access  System 
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An  immediate  application  for  a  Cronus.Link-l  1  Access  System  is  to  provide  an  en;-,' 
point  for  actual  tactical  data  and  alloi^  for  real-time  processing  of  this  data,  in  this 
role,  the  access  system  sen/es  to  aid  both  m  the  presentation  of  meaningful  NCSC 
demonstrations,  and  also  m  the  support  of  additional  development  of  distributed 
applications. 

A  testbed  which  includes  an  access  system  will  readily  support  varied  efforts  m  the 
development  of  distributed  applications  tor  the  Navy  tactical  environment.  Since  the 
access  system  performs  all  the  translation  functions  necessary  to  allow  heterogeneous 
Cronus  clients  to  freely  use  Link-11  data,  applications  which  implement  tactical 
databases,  tactical  graphics  displays  and  demonstrate  other  application  integration 
'eatures  of  the  Cronus  distributed  operating  system  can  pe  readily  assembled  A  variety 
of  hosts  can  function  both  cooperatively  and  mdvidually  to  process  Link-ll  data  and  thus 
integrate  various  discrete  data  processing  tasks  under  a  single  system.  For  example, 
existing  target  correlation,  target  track  prediction  and  target  prioritization  programs 
can  be  made  to  function  cooperatively  through  simultaneous  use  of  the  Lmk-ii  Access 
System.  The  Access  System  can  also  be  made  to  provide  long-term  storage  of  Lnk-i ' 
data  sets  for  later  retrieval  and  processing  and  for  use  m  testing  new  applications.  See 
"’gjre  3. 

Cemcnstration  of  such  applications  can  aiso  be  made  extremely  effective  through  use  o* 
the  Cronus  Monitoring  and  Control  system.  This  system  provides  passive  monitoring  o' 
the  status  and  performance  of  various  system  components  and  controls  various 
parameters  affecting  the  management  of  system  resources.  Displays  of  both 
instantaneous  and  aggregate  system  data  can  be  displayed  m  graphical  format.  ~r.is 
featu'^e  allows  tor  simple  and  effective  demonstrations  of  Cronus  interooerac-ity 


features 


provide  access  lo  laclical  data  tor  a  variety  ol  applications 
implemented  on  a  heterogenous  group  of  hosts. 
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Cronus  can  also  provide  the  basic  features  needed  to  support  significant  development 


activity  in  many  aspects  of  sunvivable  systems.  Two  fundamental  elements  of 


survivable  system  design  are  readily  supported  by  Cronus: 

•  Data  Survivability.  Cronus  supports  replication  of  data  objects.  This 
low  level  replication  feature  in  cooperation  with  resource  monitoring 
and  control,  can  form  the  basis  for  the  development  of  databases  capaoie 
of  surviving  component  failures. 

'  System  Configuration  Management  and  Control.  An  essential 
requirement  for  a  survivable  system  is  the  ability  to  monitor  the  status 
of  system  components  and  perform  resource  management  based  on  this 
status  information.  The  Cronus  Momtonng  and  Control  System  can 
form  the  basis  of  efforts  to  develop  system  features  which  will  defect 
component  failures  and  control  system  configuration  and  operation  m 
hostile  environments. 


Cronus  applications  can  be  developed  which  use  these  replication  and  momtonng  and 
control  facilities  to  implement  survivable  systems.  However,  to  completely  apply 
Cronus  facilities  for  survivability,  a  testbed  which  implements  some  degree  of 
sun/ivabilty  at  the  hardware  subsystem  level  is  required.  Development  of  a 
Cronus/Unk-1 1  Access  System  provides  an  opportunity  to  construct  a  rich  yet 
inexpensive  testbed  which  includes  hardware  subsystem  survivability.  Such  a  testbed 
can  be  cost  effective  and  easily  assembled  because  sun/ivability  is  achieved  through  the 
replication  of  inexpensive  and  readily  available  subsystems, 

A  possible  architecture  for  such  a  testbed  would  consist  of  two  or  more  gateway-styie 
PC-based  access  systems  linked  into  the  NTDS/Unk-ll  system.  Each  PC  supporting  ;ne 
interface  to  Unk-11  would  reside  on  different  Ethernets.  One  or  more  uVAX  or  SCN 
Client  machines  would  also  be  present  on  each  of  these  Ethernets  in  adcition.  at  east 
of  the  client  machines  on  each  Ethernet  would  be  dually-homed  to  the  other  Ethernet 
This  provides  fully  redundant  Ethernet  connectivity  between  each  clien,  or  group  of 
client  machines  and  each  access  pomt  to  unk-''''  See  Figure  4 
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"gure  4  Sunnvaoie  Cronus  Testbed.  This  testbed  imoiemenis  the  subsystem  redundancy 
necessary  tor  the  deveiooment.  testing  and  demonstration  ot  Cronus  apoiications  onented 
towards  survivability  Note  that  the  Access  System  Managers  are  capable  ot  supporting 
ditterent  types  ot  Access  Systems.  Also  note  that  the  Managers  are  installed  on  the 
dually-homed  hosts  to  allow  for  Manager  redundancy.  Also  note  that  this  interconnection 
scheme  is  not  limited  to  supporting  just  rwo-way  redundancy.  By  grouping  together 
suosystems.  this  testbed  can  oe  expanded  to  support  even  larger  expenments  and 
demonstrations 


This  configuration  supplies  redundancies  m  several  key  areas.  First,  there  are 
redundant  links  to  the  external  data  source,  Link-li.  Second,  should  there  be  either  an 
access  system  failure  or  any  client  host  failure,  data  can  still  be  processed  remotely 
from  the  other  set  of  client  hosts  via  the  dually-homed  host.  Third,  there  is  complete 
system  redundancy  in  the  case  of  an  Ethernet  failure. 

In  this  testbed,  Cronus  can  provide  the  necessary  control  and  replication  functions  to 
implement  survivability.  Applications  which  utilize  the  Cronus  Monitoring  and  Control 
system  can  be  developed  to  perform  system  management  and  configuration  control.  These 
applications  must  monitor  the  performance  of  various  elements  of  the  testbed  and 
command  and  control  system  reconfigurations  m  the  event  of  subsystem  failure. 

Through  the  use  of  other  Cronus  distributed  processing  facilities  such  support  for  object 
replication,  other  applications  can  be  developed  on  this  testbed  which  implement 
S’jrvivabie  databases.  In  this  environment  Cronus,  can  support  work  on  survivability 
problems  such  as  the  resolution  of  discrepancies  among  replicated  data  records  and 
'ecovery  from  database  support  subsystem  failures. 

§4  Conclusions 

in  this  document,  it  has  been  shown  that  a  CronuS/'Unk-l  1  Access  System  can  provide 
an  additional  degree  of  integration  for  the  vanous  and  diverse  command  and  control  data 
processing  tasks  m  the  Navy  tactical  environment.  Three  alternative  schemes  for  the 
implementation  of  such  an  access  system  have  been  presented  which  reflect  practical 
solutions  to  the  access  system  problem  The  merits  and  costs  of  these  mp  ementatiors 
are  summarized  below; 

PC -Based  Gateway  Madet 


Basic  Hardware  Cost 


LOW  inter'ace  and  macnine  j^'Ce' 
$'  'K 
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Development  Time; 

Punclionality; 

Cost  Effectiveness: 

Small  Quantities: 

Larger  Quantities: 

£Q-Sased  Access  Marh.nA 
Basic  Hardware  Cost; 

Development  Time: 

Functionality: 

Cost  Effectiveness; 

Small  Quantities: 

Larger  Quantities: 

mVAX-Based  Access  ^^achine  ModPi 
Basic  Hardware  Cost- 


Short:  no  Cronus  on  PC;  Link-ll 
Manager  will  be  built  for  mature 
Cronus  host. 

PC  supports  no  Cronus  functionality, 
split  in  functionality  between  two 
machines  may  present  limitations  m 
security,  performance  and 
reliability.  PC  cannot  directly 
support  storage  but  storage  function 
can  be  applied  to  Cronus  host 
supporting  Link-11  manager. 


High. 

High. 


Low:  interface  and  machine  under 
$1  IK. 

Short  term  or  longer  term  depending 
on  needs  for  performance:  PC  UNIX 
can  support  rapid  implementation 
will  possibly  limited  performance: 
a  custom  multitasking  environment 
can  provide  higher  performance  and 
optimization. 

Since  system  is  built  on  a  single 
machine  which  communicates  with 
other  Cronus  hosts  via  iPC, 
reliability  and  security  will  be  high. 
Performance  will  depend  on 
implementation.  Storage  capacity 
will  be  limited. 


High  if  PC  UNIX  is  used:  lower  if 
Custom  multitasking  system  is 
developed. 

Higher. 


High:  especially  if  processor  must 
be  newly  procured 


i«u  u^iiiiiig  aysierns 


Development  Time: 


Functionality: 


Cost  Effectiveness: 

Smalt  Quantities: 


Larger  Quantities: 


Medium:  Integration  of  Lmk-ii 
interface  with  existing  software 
could  be  difficult. 

Since  system  is  built  on  a  single 
machine  which  communicates  with 
other  Cronus  hosts  via  IPC, 
reliability  and  security  will  be  high 
Performance  will  be  very  high  Few 
storage  limitations. 


Low  to  Moderate  depending  on  need  to 
procure  processor 

Low. 


All  three  implementation  schemes  provide  the  necessary  integration  between 
NTDS/Link-1 1  and  a  Cronus  testbed  and  provide  broad  opportunities  for  the 
development  and  demonstration  of  key  aspects  of  distributed  processing  technology  and 
for  future  growth  and  research.  Selection  among  the  schemes  will  be  based  on  needs  ‘or 
functionality  and  testbed  flexibility  and  the  resources  available  to  support  the  access 


system  task. 


